Ideally, the vector tiles would indicate the country code of each feature, as the Mapbox Streets source does. In lieu of that convenience, I manually drew polygons that cover the major signage regions, saved them in GeoJSON format, inlined each one into a within expression (to test whether the feature lies within the polygon), and finally embedded this expression inside each image component of the text-field expression representing one shield in a concurrency.

This bloats the style JSON to a whopping 0.99 MB (1,034,181 bytes), far above the high water mark set in #666. Part of the problem is that this expression gets repeated six times, since we support up to a six-way concurrency. Unfortunately, GL JS requires the within expression’s argument to be a literal object and refuses to evaluate it as an expression, so we can’t bind a variable to the GeoJSON object and reuse it multiple times within the overall expression.

We could optimize the GeoJSONs a bit more, for example by reducing coordinate precision, but I’ve already simplified each country’s borders very aggressively. Most of the polygons are essentially a convex polygon around the country’s international border crossings, with some extra buffer to include the country’s trunk road network in full. Clearly our support for this network would benefit from either more granular tagging or more thorough postprocessing.

This wiki page specifies network=AsianHighway for Asian Highway routes (along with int_ref, grr), but a significant minority of routes are tagged network=AH instead. I can’t find any discussion of using AH anywhere, so it’s probably just a lack of awareness about the AsianHighway standard. A two-letter code like AH would be problematic anyways, because it would be easily confused with a (nonexistent) ISO 3166-1 country code.

Sounds like a strong case against supporting network=AH. I would rather leave it out to encourage mappers to use a standard tagging scheme.

Indeed, I’m definitely planning to remove support for it before merging. For now, though, it is necessary for demonstrating some of the cross-border differences in shield designs, because they happen to coincide with cross-border differences in how some route relations have been tagged. (I suspect it’s an oversight rather than anything intentional.)

This polygon has two outer rings. It should be a multipolygon geometry instead. GL JS has no problem with this weirdly-formed polygon, but for instance GitHub’s GeoJSON previewer makes a mess of it.